Проверка функций «Управление журналированием событий»

Разворачивание сервера журнала событий

Шаги проверки

Ожидаемый результат

Шаг 1

Перейти: Журнал событий → Серверы журнала событий → Вкладка «Серверы журнала событий».

Отображается таблица с перечнем всех серверов журнала событий в системе - таблица пустая.

Шаг 2

Нажать на кнопку «+ Развернуть сервер журнала событий».

Отображается форма добавления нового сервера журнала событий.

Шаг 3

Заполнить поля формы:

  1. В поле «Имя компьютера» выполнить поиск компьютера, который будет выполнять роль сервера журнала событий. В выпадающем списке выбрать компьютер, который будет выступать в роли сервера журнала событий.

  2. В поле «Роль» выбрать «Основной сервер».

  3. В списке «Имя сайта» выбрать любое значение.

Нажать на иконку сохранения и подтвердить операцию.

Данные для заполнения

  1. «Имя компьютера» = «audit*»

  2. «Имя сайта» = «Головной офис»

Запущен процесс разворачивания сервера audit*. Пользователь перенаправлен на вкладку «Серверы журнала событий».

Шаг 4

Перейти в карточку сервера журналирования событий «audit*», который был развернут на шаге №3.

Отображена карточка выбранного сервера журналирования событий. С левой стороны отображена форма метаданных, содержащая следующие элементы:

  1. Заголовок с полным наименованием машины «audit*»;

  2. Поле «Подсистема» содержит значение «Журналирование событий»»;

  3. Поле «Состояние подсистемы» - статус «Устанавливается»;

  4. Поле «Дата создания» - содержит дату отправки задания на разворачивание (формат ДД.ММ.ГГГГ, ЧЧ:ММ:СС) на шаге №3;

  5. Поле «Дата обновления» - содержит значение из поля «Дата создания»;

  6. Поле «Версия ALD Pro» - заглушка «Неизвестно»;

  7. Кнопка «Обновить ALD Pro» - функционально и визуально не активна;

  8. Кнопка «Удалить» - функционально и визуально не активна;

  9. Кнопка «Открыть журнал событий» - визуально и функционально активна.

Шаг 5

Перейти: Журнал событий → Серверы журнала событий → Вкладка «Серверы журнала событий».

Столбец «Имя сервера» таблицы содержит значение «audit*».

Создание карточки правила сбора событий

Требования:

В системе успешно развернута подсистема журнала событий условное обозначение audit01.

Шаги проверки

Ожидаемый результат

Шаг 1

Перейти: Журнал событий → Настройка сбора журналов событий

Отображается страница «Правила сбора событий».

Шаг 2

Нажать кнопку «+ Новое правило».

Отображается форма создания правила сбора событий.

Отображаются поля обязательные для заполнения:

  • Имя правила.

  • Тип логов.

  • Сервер сбора логов.

Поле «Описание» пустое и доступно для заполнения.

Состояние по умолчанию «Выключено».

Кнопка «Сохранить» не активна.

Кнопка «Закрыть» функционально активна.

Шаг 3

Заполнить поля:

  • Имя правила.

  • Тип логов.

  • Сервер сбора логов.

  • Описание

Нажать кнопку «Сохранить» и подтвердить операцию.

Данные для заполнения:

«Имя правила» - «rule1»

«Тип логов» - любой тип логов, который не добавлен в системе.

«Сервер сбора логов» - сервер из п.2 Требования.

«Описание» - «Тестовое описание»

  1. Выводится уведомление об успехе операции.

  2. Отображается карточка правила «rule1».

  3. Поля «Имя правила», «Тип логов», «Сервер сбора логов» не доступны для редактирования.

  4. В поле «Описание» присутствует введенное значение, поле доступно для редактирования.

Появился аккордеон «Свойства», который содержит нередактируемые поля:

  1. Дата создания

  2. Дата изменения

  3. Версия

  4. Автор изменений

Шаг 4

Повторить шаги 1-2.

ОР соответствует шагов 1-2.

Шаг 5

Заполнить обязательные поля:

  • Имя правила.

  • Тип логов.

  • Сервер сбора логов.

Нажать кнопку «Сохранить» и подтвердить операцию.

Данные для заполнения:

«Имя правила» - «rule2»

«Тип логов» - тип логов выбранный на шаге №3.

«Сервер сбора логов» - сервер из п.2 Требования.

Выводится уведомление об ошибке. Нельзя создавать правила с одинаковым типом логов.

Шаг 6

Изменить значения в полях:

  • Имя правила.

  • Тип логов.

Нажать кнопку «Сохранить» и подтвердить операцию.

Данные для заполнения:

«Имя правила» - «rule1»

«Тип логов» - выбрать значение, отличающееся от значений в других правилах.

Выводится уведомление об ошибке. Нельзя создавать правила с одинаковым наименованием.

Шаг 7

Изменить значения в полях:

  • Имя правила.

  • Статус.

Нажать кнопку «Сохранить» и подтвердить операцию.

Данные для заполнения:

«Имя правила» - «rule2»

«Статус» - «Включено»

  1. Выводится уведомление об успехе операции.

  2. Отображается карточка правила «rule2».

  3. Поля «Имя правила», «Тип логов», «Сервер сбора логов» не доступны для редактирования.

  4. Состояние правила «Включено».

Появился аккордеон «Свойства», который содержит нередактируемые поля:

  1. Дата создания

  2. Дата изменения

  3. Версия

  4. Автор изменений

Шаг 8

Перейти: Журнал событий → Настройка сбора журналов событий

  1. Отображается страница «Правила сбора событий».

  2. В таблице отображаются правила созданные на шагах №3 и №7.

  3. Если в системе присутствовало еще правило, оно так же отображается в списке.

Сбор событий «Логи авторизации Fly»

В системе присутствует правило сбора событий rule1.

  1. Тип логов - «Логи авторизации Fly».

  2. Состояние - «Выключено».

  3. Правило ни разу не редактировалось.

Шаги проверки

Ожидаемый результат

Шаг 1

Перейти: Журнал событий → Настройка сбора журнала событий → Карточка правила rule1. Включить правило.

Подождать срабатывание таймера на client01 и audit01.

Правило rule1 успешно включено.

Таймер успешно отработан на машинах client01 и audit01. Pillar обновлен, новая конфигурация применена.

Шаг 2

В графическом интерфейсе ОС на клиенте client01 выполнить вход под УЗ user1.

Вход выполнен успешно

Шаг 3

Выполнить подключение по ssh к серверу аудита (audit01) под УЗ с правами sudo (например, astra или admin):

  • ssh admin@<IP-адрес сервера>

Подключение выполнено успешно

Шаг 4

Перейти в директорию сбора логов: /var/log/aldpro.

Переход в директорию выполнен успешно.

Шаг 5

Открыть на чтение в директории /var/log/aldpro файл fly_<имя правила rule1>.log.

Прим.: информация в pillar обновляется по истечению времени, установленном в шедуллере + оффсет (до 30 мин). Конфигурация применяется также по истечению времени, установленном в соответствующем шедуллере (по умолчанию срабатывает при включении компьютера, далее - раз в 30 минут).

Пока конфигурация не применена, логи не собираются.

Информация о действии шага 2 не отображена.

Шаг 6

После обновления информации в pillar и применении настроенной конфигурации правила сбора событий, в графическом интерфейсе ОС на клиенте client01 выполнить вход под УЗ user1.

Вход выполнен успешно

Шаг 7

Вернуться к открытому файлу логов на шаге 5.

В файле отображается запись об авторизации пользователем user1 на client01 на шаге №6.

Шаг 8

Выполнить любое действие, попадающее под тип логов отличного от правила rule1.

Действие выполнено успешно

Шаг 9

Вернуться к открытому на шаге №5 файлу логов.

В файле не отображается информация о действии, выполненном на предыдущем шаге.

Сбор событий «Логи удаленного подключения»

В системе присутствует правило сбора событий rule1.

  1. Тип логов - «Логи удаленного подключения».

  2. Состояние - «Выключено».

  3. Правило ни разу не редактировалось.

Шаги проверки

Ожидаемый результат

Шаг 1

Перейти: Журнал событий → Настройка сбора журнала событий → Карточка правила rule1. Включить правило.

Подождать срабатывание таймера на client01 и audit01.

Прим.: обновление pillar и последующее применение конфигурации производится после срабатывания таймера. По умолчанию - 30 минут + оффсет (от 5 до 50 минут).

Правило успешно включено.

Таймер успешно отработан на машинах client01 и audit01. Pillar обновлен, новая конфигурация применена.

Шаг 2

Выполнить подключение по ssh к компьютеру client1 под УЗ user1.

  • ssh user1@<IP-адрес клиента>

Подключение выполнено успешно

Шаг 3

Выполнить подключение по ssh к серверу аудита audit01 под УЗ с правами sudo (например, astra или admin):

  • ssh admin@<IP-адрес сервера>

Подключение выполнено успешно

Шаг 4

Перейти в директорию сбора логов: /var/log/aldpro.

Переход в директорию выполнен успешно

Шаг 5

Открыть на чтение в директории /var/log/aldpro файл connection_<имя правила rule1>.log.

Данные:

sudo tail -f /var/log/aldpro/connection_<имя правила rule1>.log

Информация о действии шага 2 отображена в логах

Шаг 6

На client01 выполнить любое действие, попадающее под тип логов, отличного от правила rule1.

Действие выполнено успешно

Шаг 7

Вернуться к открытому на шаге №5 файлу логов.

В файле не отображается информация о действии, выполненном на предыдущем шаге.

Сбор событий «Логи состояния подключения к сети»

В системе присутствует правило сбора событий rule1.

  1. Тип логов - «Логи состояния подключения к сети».

  2. Состояние - «Выключено».

  3. Правило ни разу не редактировалось.

Шаги проверки

Ожидаемый результат

Шаг 1

Перейти: Журнал событий → Настройка сбора журнала событий → Карточка правила rule1. Включить правило.

Подождать срабатывание таймера на client01 и audit01.

Правило успешно включено

Таймер успешно отработан на машинах client01 и audit01. Pillar обновлен, новая конфигурация применена.

Шаг 2

Выполнить вход на компьютер client01 под УЗ администратора (например, astra или admin).

Вход выполнен успешно.

Шаг 3

Изменить состояние подключения клиента к сети любым доступным действием на выбор:

  1. Перезапустить службу «network-manager» (sudo systemctl restart network-manager.service).

  2. В графическом интерфейсе клиента: нажать ПКМ по иконке сетевого соединения на панели задач, убрать чекбокс «Включить поддержку сети». Затем снова включить «Поддержку сети» и дождаться восстановления подключения.

Состояние подключения к сети изменено успешно.

Шаг 4

Выполнить подключение по ssh к серверу аудита audit01 под УЗ с правами sudo (например, astra или admin):

  • ssh admin@<IP-адрес сервера>

Подключение выполнено успешно

Шаг 5

Перейти в директорию сбора логов: /var/log/aldpro/.

Переход в директорию выполнен успешно

Шаг 6

Открыть на чтение в директории /var/log/aldpro файл network_<имя правила rule1>.log.

Информация о действии шага №3 отображена в логе.

Шаг 7

Выполнить любое действие, попадающее под тип логов, отличного от правила rule1.

Действие выполнено успешно.

Шаг 8

Вернуться к открытому на шаге №6 файлу логов.

В файле не отображается информация о действии, выполненном на предыдущем шаге.

Управление подсистемой журнала событий - работа привилегий объекта «Event Log Servers»

В системе создана пользовательская роль (условное обозначение - role), которая отвечает следующим требованиям:

  1. Для роли добавлены привилегии:

    1. «Event Log Servers - Create» и «Event Log Servers - Drop» - настроены для сайта «site01».

    2. Две привилегии «Event Log Servers - Modify»:

      1. Первая привилегия «Event Log Servers - Modify» настроена для сайта «site01».

      2. Вторая привилегия «Event Log Servers - Modify» настроена для сайта «site02».

    3. «Event Log Servers - Read» и все необходимые зависимые привилегии (IPA Servers - Read, Sites - Read, Computers - Read, Organization units - Read, DNS Zones - Read).

  2. Роль находится в состоянии «Активна».

  3. Роль назначена на подразделение А, опция «Включая дочерние подразделения» выбрана.

  4. Участниками роли являются только следующие объекты: пользователь user1 и группа пользователей group1.

  5. Пользователь user1 входит только в роль role и группу по умолчанию.

  6. Группа пользователей group1 содержит как минимум пользователя user2:

    1. Группа group1 не входит ни в какие группы пользователей (прямо или косвенно), на нее назначена только роль role.

    2. Пользователь user2 входит только в группу group1 и группу по умолчанию, на него не назначено никаких ролей (прямо или косвенно - кроме role).

  7. В системе настроена структура подразделений - как минимум добавлено подразделение А, являющееся дочерним для корня. Подразделение А имеет дочернее подразделение А1.

  8. В системе создано любое количество сайтов, в том числе сайт «site01», «site02» и «site03».

  9. В системе присутствует минимум три машины, на которых можно развернуть подсистемы журнала событий:

    1. Машина audit01 входит в подразделение A.

    2. Машина audit02 входит в подразделение A1.

    3. Машина host1 входит в корневом подразделение.

  10. На компьютере audit03 (состоит в корневом подразделении) развернута подсистема журнала событий, настроенная на сайт site03.

  11. На компьютерах audit01, audit02 и host1 не развернуто никаких подсистем.

  12. В домене присутствует учетная запись с правами администратора (условное обозначение admin).

Шаги проверки

Ожидаемый результат

Шаг 1

Выполнить вход на ПУ под УЗ admin.

Вход выполнен успешно.

Шаг 2

Перейти «Журнал событий» → «Серверы журнала событий» → Карточка сервера audit01.

  1. Изменить поле «Имя сайта» выбрав значение site02.

  2. Нажать кнопку «Сохранить» и подтвердить действие.

Откроется карточка выбранного сервера

Шаг 3

Перейти «Журнал событий» → «Серверы журнала событий» → Карточка сервера audit02.

  1. Изменить поле «Имя сайта» выбрав значение site02.

  2. Нажать кнопку «Сохранить» и подтвердить действие.

Отображено уведомление об успешной операции.

Сайт сервера изменен.

Шаг 4

Перейти «Журнал событий» → «Серверы журнала событий» → Карточка сервера audit03.

  1. Изменить поле «Имя сайта» выбрав значение site01.

  2. Нажать кнопку «Сохранить» и подтвердить действие.

Отображено уведомление об успешной операции.

Сайт сервера изменен.

Шаг 5

Выполнить вход на ПУ под УЗ user1.

Вход выполнен успешно.

Шаг 6

Перейти «Журнал событий» → «Серверы журнала событий» → Карточка сервера audit01.

  1. Изменить поле «Имя сайта» выбрав значение site01.

  2. Нажать кнопку «Сохранить» и подтвердить действие.

Выводится уведомление об успехе операции.

  • В поле «Имя сайта» отображается выбранный сайт.

Шаг 7

Перейти «Журнал событий» → «Серверы журнала событий» → Карточка сервера audit02.

  1. Изменить поле «Имя сайта» выбрав значение site01.

  2. Нажать кнопку «Сохранить» и подтвердить действие.

Выводится уведомление об успехе операции.

  • В поле «Имя сайта» отображается выбранный сайт.

Шаг 8

Перейти по URLу любой страницы любого раздела, которая недоступна данному пользователю.

Отображена заглушка «404» - пользователю недоступна выбранная форма.